<div id="copy">
	
<div id="sidebar">
	<hr/>
	<a href="#server-mode">Server Mode</a>
	<hr/>
	<a href="#rollout">Roll Out</a>
	<hr/>
	<a href="#update">Site Update</a>
	<hr/>
	<a href="#logging">Logging</a>
	<hr/>
	<a href="#users">Users</a>
	<hr/>
</div>

<div id="bodyCopy">
	<span id="floatLeft"><img src="/img/cc-bynd-mr-t-in-dc-flickr-4286854004.jpg" width=280px alt="Deployment"/></span>
	<h3 id="server-mode">Server Mode</h3>
	<p>Gobl can be deployed in one of the following modes: live-update mode, batch-update mode and sealed mode.
	</p>
	<p><em>CMS mode</em> means that edits are made directly in the server from the web GUI and the edits will show up immediately to site visitors.
	</p>
	<p><em>Live-update mode</em> means that edits are made in another server (e.g. staging / development server).  Contents must be moved manually to production server by sysadmin / webmasters before site visitors can see them.  By removing user login, this mode takes that aspect of hackability out of the equation.
	</p>
	<p><em>Bunker mode</em> is essentially batch-update mode where content update is disabled.  The only way to update the site is by restarting the server.  This mode is even less hackable than batch-update mode because changes can only be made if you have access to restart the server.  Obviously, if you only have a single production server, then a restart will bring the site down (for a minute).  But if you have more than one server, then you can avoid down time by letting your load balancer do the smart work.
	</p>
	
	<p><em>CMS mode:</em> Set "ServeRPC" to false. And use <span id="code">-r=cms</span>.
	</p>
	<p><em>Live-update mode:</em> Set "ServeRPC" to true. And use <span id="code">-r=ws</span>.
	</p>
	<p><em>Bunker mode:</em> Set "ServeRPC" to false. And use <span id="code">-r=ws</span>.
	</p>
	
	<h3 id="rollout">Roll Out</h3>
	
	<p>Web site deployment involves business process, not just technical process.  Different web site / project / company can have different deployment process.
	</p>
	<p>I assume you will use separate staging and production server; at least logically separate, if not physically separate.  In staging server, you obviously need to run it in CMS mode, so you can make changes dynamically on the fly.  In production server, you can use either CMS mode, live-update mode, or bunker mode.
	</p>
	<p>Here is a scenario for workflow taken from my personal workflow for this web site.
	</p>
	<ol>
		<li>Create / edit marked up contents in HTML editor.  (I use <a href="http://geany.org/" title="Geany">Geany</a>.)  This step is optional, but highly recommended.</li>
		<li>Copy the content to staging server running on my laptop and QC the pages.</li>
		<li>Copy files to production server.</li>
		<li>Perform <span id="code">-r=restore</span> in production server.</li>
	</ol>
	<p>The workflow for an enterprise web site, depending on your project and organisation, can be more involved.  Actual steps and actors will vary, but the following scenario simulates an enterprise web site work flow.  Remember, this is only an illustration.
	</p>
	<ol>
		<li>You may have copy writer(s) - this could be just you - who develop the content copy.  The copy can be written in any editor.</li>
		<li>Mark up or edit the copy in your favourite HTML editor.  Adjust the CSS/JS if needed.</li>
		<li>Paste the marked up contents into Gobl staging server and do QC there.</li>
		<li>Version control the files.</li>
		<li>Reviewers then access the staging server (as site visitors) to review and comment.</li>
		<li>Do final changes and QC.</li>
		<li>Version control the files.</li>
		<li>Copy the files to production server.</li>
		<li>Perform <span id="code">-r=restore</span> to update the production server with the latest changes.  (This assumes you use live-update mode.)</li>
	</ol>
	<p>Those who manage the design / drafting in the staging server can be different from those who actually manage the contents in production server.</p>
	
	<h4><em>Tweaking</em></h4>
	
	<p>For production server, you can very easily comment out or delete sections of code that is not part of the "web server" and compile it for production-specific runtime.  You will end up with two runtime, one for CMS and one for web server.  Having a web server-only runtime may reduce Gobl memory footprint and may tighten things up a bit.
	</p>
	<p>I do not think it matters too much except in the extreme scenarios, so I decided to keep the code in only one file and use CLI flag to differentiate between CMS mode and live-update/bunker mode via <span id="code">-r=cms</span> (run CMS mode) or <span id="code">-r=ws</span> (run web server mode).  I could have produced multiple files or multiple packages, but since you need to compile anyway, it is easy enough to just adjust the source code as described above.
	</p>
	
	<h3 id="update">Site Update</h3>
	
	<p>Assuming you run the web server in live-update mode and ServeRPC is set to true in configuration, then the server update is initiated via CLI, which can be done even from a remote server if the communication process is configured accordingly.  Run <span id="code">-c=restore</span>.
	</p>
	<p>There are a few objects related to restore: user configuration file, snippet files and copy files.  Although these objects are editable in the back end (e.g. using vi or nano), editing them will not have an impact to a running website, unless a restore step is performed to load the data from files to memory.  Gobl runs from memory for the most part and restore is the only mechanism to load the objects into memory.
	</p>
	<ol>
		<li>Set ServeRPC to true.</li>
		<li>Set RPCConnType, e.g. tcp, unix, etc (golang.org/pkg/net/#Listen)</li>
		<li>Set RPCConnAddr, e.g. localhost:4321 (this can be elsewhere in the internet if you use tcp type)</li>
	</ol>
	<p>You can run Gobl in Production with ServeRPC set to false, if you want, but that means that updating the web site will require a restart, since update is done only by restore.  If you run Gobl in CMS mode, then updates can be done directly in the CMS web GUI.
	</p>
			
	<h3 id="logging">Gobl Logging</h3>
	
	<p>Gobl has system logging and web logging.  <em>System log</em> records messages that the server spits out from time to time, such as errors.  <em>Web log</em> records which page was served to which ip address and when.
	</p>
	<p>System log file, by default, are saved on the same server and the file name starts with "slog".
	</p>
	<p>Web logs are spit out to Gobl web logger on another machine / server.  This is an experimental feature that should only be used when you are expecting very high traffic volume that need to be logged.  The intention is to offload the burden away from the web server to the web logger so the web server can focus on serving pages only.
	</p>
	<ol>
		<li>Set ServeWebLogging to true.</li>
		<li>Set WebLogChannelType, e.g. tcp</li>
		<li>Set WebLogChannelAddr, e.g. localhost:4321 (this can be elsewhere in the internet if you use tcp type)</li>
		<li>Set WebLogChannelName, e.g. gobldigook</li>
	</ol>
	
	<h3 id="users">Users</h3>
	
	<p>In this section we are talking about CMS users, i.e. the web administrators, not the web site visitors.  Gobl does not support site visitor login yet. And there is only one type of CMS user / web admin without any separation of roles or access among the web admins.  Each user can update his/her and other user's profile from the GUI.
	</p>
	<p>Initial admin user and password for Gobl is "root" (without the quotes and case sensitive). See the configs/users.json file. Generally, if you have any CMS mode website (at least your staging server must be in CMS mode), the thing to do after starting the server for the very first time is to change the passwords of the initial user.
	</p>
	<p>The overly simplistic (web admin) user management is because Gobl is primarily designed for use by a small team of deployment engineers / web admin.
	</p>
	
</div>

</div>
